OpenEdge Development: <br />Web Services Handling Web service errors

As with invocation of any 4GL statement, invoking a Web service operation can raise an ERROR condition that you can handle in exactly the same way as an other 4GL statement error. The ERROR condition from a Web service request can result from one of three basic causes:

A SOAP fault returned by the Web service.

A 4GL internal error raised by OpenEdge.

An error intentionally raised by the 4GL application (using the RETURN ERROR statement) in one of the following procedures:

SOAP request header callback procedure.

SOAP response header callback procedure.

SOAP fault errors

For a SOAP fault, you start out by handling the ERROR condition as usual in the 4GL, whether it is:

Following the invocation of a synchronous Web service request.

In the event procedure of an asynchronous Web service request.

If the Web service returns a SOAP fault from an error detected while processing a Web service request, OpenEdge receives the SOAP fault and turns it into a Progress error message. If the statement that invoked the request includes the NO-ERROR option, OpenEdge also attaches the error message to the ERROR-STATUS system handle.

You can identify this error as a SOAP fault by the content of this message (using the GET-MESSAGE( ) method) and also by examining the object referenced by the ERROR-OBJECT-DETAIL attribute on the ERROR-STATUS handle. If the error resulted from a SOAP fault, this attribute references a SOAP fault object, which in turn references an optional SOAP fault-detail object, depending on the Web service application.

If there is no SOAP fault-detail object, you can get all the information available on the SOAP fault from the remaining attributes of the SOAP fault object and the methods of the ERROR-STATUS system handle.

If there is a SOAP fault-detail object, it likely stores more information about the SOAP fault in XML defined by the Web service. You can access this XML in much the same way you access the XML for a SOAP header entry (see the "Handling the information in SOAP headers" section). That is, if the WSDL Analyzer identifies a temp-table or ProDataSet that can represent the SOAP fault-detail object, it provides the temp-table or ProDataSet definition for you to use, if you choose. Otherwise, you can obtain this SOAP fault information as a serialized XML string or as a DOM tree that you must interpret as required using the DOM or SAX tools provided in the Progress 4GL.

4GL internal errors

You can handle an internal ERROR condition raised for invocation of a 4GL statement as usual by trapping it with the ON ERROR option or inspecting the ERROR-STATUS system handle directly after invoking the request with the NO-ERROR option.

Errors raised by the application

Within a SOAP header callback procedure you can invoke the RETURN ERROR statement as though it were part of the 4GL statement that generated the request so it can be trapped using standard 4GL error handling. However, for an asynchronous Web service request, an unhandled internal error or RETURN ERROR statement invoked in the SOAP response header callback procedure is propagated from the callback to the event procedure, rather than the point following invocation of the asynchronous request (see the "Managing asynchronous requests" section).

One reason to invoke RETURN ERROR in a SOAP header response callback procedure is to respond to a SOAP header fault. You must determine that there is an error in the header of a SOAP response message by inspecting the header XML. OpenEdge does not otherwise detect a SOAP header fault returned from a Web service.